Different telecommunication or data communication services may have different positioning accuracy requirements imposed by the application. In addition, some regulatory requirements on the positioning accuracy for basic emergency services exist in some countries, i.e. FCC E911 in the US.
In many environments, the position can be accurately estimated by using positioning methods based on GPS (Global Positioning System). Nowadays networks have also often a possibility to assist the user equipment, UE in order to improve the terminal receiver sensitivity and GPS start-up performance (such as Assisted-GPS positioning, or A-GPS). GPS or A-GPS receivers, however, may be not necessarily available in all wireless terminals. Furthermore, GPS is known to often fail in indoor environments and urban canyons. A complementary terrestrial positioning method, called Observed Time Difference of Arrival OTDOA, has therefore been standardized by 3GPP. In addition to OTDOA, the Long Term Evolution, LTE standard also specifies methods, procedures and signaling support for Enhanced Cell ID, E-CID and Assisted Global Navigation Satellite System, A-GNSS. Another method, Uplink Time Difference of Arrival, UTDOA is also under consideration for LTE.
Positioning in a LTE communication network involves a number of network elements. An overview is found in FIG. 1. The communication network 100 includes an Evolved Serving Mobile Location Center, E-SMLC 111. The E-SMLC 111 can be connected to a plurality of Mobility Management Entities, MME 121-132 in more than one MME pool 120,130. Each MME 121-132 can serve a plurality of bases stations, also called evolved Node B, eNodeB 141-153. The eNodeBs served by an MME pool 120,130 serves terminals or user equipments, UE (not shown) in a so called MME pool area 140,150. MME pool areas 140,150 may overlap each other 160.
In the LTE positioning architecture there are three key network elements, the LCS Client, the LCS target and the LCS Server. The LCS Server is a physical or logical entity managing positioning for a LCS target device by collecting measurements and other location information, assisting the terminal in measurements when necessary, and estimating the LCS target location. A LCS Client is a software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location information for one or more LCS targets, i.e. the entities being positioned. LCS Clients may reside in the LCS targets themselves. An LCS Client sends a request to LCS Server to obtain location information, and LCS Server processes and serves the received requests and sends the positioning result and optionally a velocity estimate to the LCS Client. A positioning request can be originated from the terminal or the network.
Position calculation can be conducted, for example, by a positioning server (e.g. E-SMLC in LTE) or a UE. The former approach corresponds to the UE-assisted positioning mode, whilst the latter corresponds to the UE-based positioning mode.
A high-level positioning architecture, as it is currently standardized in LTE, is illustrated in FIG. 2. The LCS target is a UE 240 and the LCS Server is an E-SMLC 111 or a Secure User Plane Location Platform SLP 112. If both an E-SMLC 111 and an SLP 112 is used, the interface in between is normally a proprietary interface 113.
Two positioning protocols operating via the radio network exist in LTE, the LTE Positioning Protocols, LPP and LLP Annex, LPPa. The LPP is a point-to-point protocol between a LCS Server 111 and a LCS target device 240, used in order to position the target device 240. LPP can be used both in the user and control plane, and multiple LPP procedures are allowed in series and/or in parallel thereby reducing latency. LPPa is a protocol between eNodeB 141 and the LCS Server 111 specified only for control-plane C positioning procedures, although it still can assist user-plane positioning by querying eNodeBs for information and eNodeB measurements. The SUPL protocol is used as a transport for LPP in the user plane U. LPP has also a possibility to convey LPP extension messages inside LPP messages, e.g. to allow for operator-specific assistance data or assistance data that cannot be provided with LPP or to support other position reporting formats or new positioning methods.
Assistance data is intended to assist a UE 240 or another network node in its positioning measurements. Different sets of assistance data is typically used for different methods. The OTDOA assistance data include a number of parameters as specified in the standard 3GPP TS 36.355. For example, some parameters may be used for determining the timing relation between a Positioning Reference Signal, received in the first sub frames of the positioning occasions of two cells.
In the case of combined Control Plane/User Plane, CP/UP operation, these parameters are expected to be extracted by the E-SMLC 111 from the eNodeBs 141 via the LTE Positioning Protocol LPPa and provided to the SLP 112 via interface 113. The LPPa messages are encapsulated in Location Services Application Protocol, LCS-AP connectionless transfer procedure messages.
Furthermore, using the protocol extension LPPe there is also a possibility of carrying over a black-box data container meant for carrying vendor-/operator-specific assistance data from the eNodeB 141 via the MME 121.
For combined CP/UP operation, it is currently not possible to obtain routing information of the connectionless transfer procedures. Although LPPa is terminated between the E-SMLC 111 and the eNodeB 141, the E-SMLC 111 must contact the MME 121 having a S1 connection to the destination eNodeB 141 for connectionless transfer message delivery.
For an E-SMLC which serves one MME or one MME pool, the routing is normally not a problem because all MMEs in one MME pool can be contacted for connectionless transfer. However, if the E-SMLC 111 is connected to more than one MME pool 120,130, the mapping (i.e. the associations) between the identities of the eNodeBs 141 and the MME pool 120,130 serving the eNodeBs 141 are necessary for such routing.
One solution is to import a mapping table from an Operations Support System OSS, but this may for various reasons not be possible or feasible.
Another approach is to make a eNodeB 141 to MME pool 120,130 mapping table as an E-SMLC configuration. Such configuration is however time consuming and also subject to input/manual errors.